SAP Deadline : 2027 - opportunité stratégique ou moyen de pression coûteux ?

La date limite de support oblige les entreprises à faire un pas qui ressemble souvent plus à une obligation imposée qu'à une décision stratégique.

L'échéance ECC de 2027 est actuellement l'argument de vente le plus fort de SAP - mais en fait, elle ne devrait pas l'être. Avec S/4 Hana, il ne s'agit pas en premier lieu de technique, mais de la pérennité de toute l'entreprise. Mais celui qui agit uniquement par peur de la fin du support tombe dans un piège dangereux : l'investissement peut alors à peine être justifié par un business case solide. Nous savons tous comment cette histoire se termine : Si la justification d'un projet est faible, le budget alloué le sera aussi.

Parallèlement, en l'absence d'une orientation stratégique claire, le soutien nécessaire de la direction fait défaut, ce qui entraîne un affaiblissement progressif du soutien au projet. SAP a déjà repoussé quatre fois la fin de la maintenance d'ECC, de 2017 à 2027 (ou 2030 sous certaines conditions), en passant par 2019 et 2025.

Chaque fois, on nous a dit que la date était définitive, et chaque fois, elle a été repoussée parce que le marché n'était pas encore prêt. Il faut le dire clairement : Le 31 décembre 2027 n'est pas un événement technique, mais un instrument commercial que l'organisation commerciale de SAP utilise avec maestria.

Le coût de la prolongation

Après 2027, SAP propose certes une maintenance étendue jusqu'en 2030, mais uniquement sous des conditions clairement définies et restrictives. Ainsi, une majoration supplémentaire de 2 % est appliquée aux frais de maintenance existants, ce qui est effectivement présenté par SAP comme un surcoût d'environ 9 %. Parallèlement, la qualification pour cette maintenance prolongée est liée à l'acquisition par les entreprises de licences pour S/4 au plus tard jusqu'en 2027. Celles qui ne prennent pas cet engagement tombent automatiquement dans ce que l'on appelle la „maintenance spécifique au client“ - un domaine sans listes de prix publiées et donc avec des risques financiers difficilement calculables.

Le piège de la négociation panique

Les entreprises qui n'agissent que 90 jours avant l'échéance perdent tout leur pouvoir de négociation. Elles acceptent souvent la première offre de rise venue, juste pour ne pas perdre le support. Il en résulte des contrats bâillons aux conséquences importantes et souvent fatales. Les entreprises acceptent souvent les abonnements basés sur le FUE sans comparaison de prix solide et sans analyse approfondie et optimisation des autorisations réellement nécessaires. Parallèlement, il en résulte une destruction de valeur considérable, car des licences à durée indéterminée dans lesquelles des millions ont déjà été investis sont abandonnées. À cela s'ajoutent des risques contractuels, comme l'absence de plafonds de prix lors du renouvellement des contrats ou l'expiration des unités de capacité BTP, BDC et AI ou des crédits selon le principe „use it or lose it“. En outre, une réduction sensible des coûts du FUE n'est pas en vue à moyen terme. L'échéance de 2027 n'entraîne pas directement de dépenses supplémentaires, mais elle raccourcit si massivement la fenêtre de négociation que les pertes financières deviennent presque inévitables.

Expiration des crédits de capacité

Dans le cadre du Cloud Platform Enterprise Agreement (CPEA), le client s'engage chaque année à acheter des Cloud Credits. Ces crédits peuvent être utilisés de diverses manières, que ce soit pour l'analytique, l'automatisation des processus, l'IA ou les développements spécifiques au client (hors standard, pfui !). À la fin de chaque période annuelle, le solde est remis à zéro. Les crédits non utilisés expirent. Il n'est pas possible de les transférer. Le compteur repart à zéro.

Un modèle commercial lucratif

La plupart des entreprises ne consomment que 40 à 60% des crédits qui leur ont été attribués et l'allocation pour l'année suivante commence au même niveau promis, indépendamment de la consommation réelle. Le défi réside dans le fait que la plupart des entreprises ne peuvent pas baser leur engagement BTP ou IA sur leurs propres données de consommation, car ces services n'existent pas encore. Vous vous engagez à un pool de crédits avant de développer et/ou d'utiliser les applications. L'architecture des prix pénalise les sur-licences et les sous-licences. La consommation de la première année est faible, car les projets sont encore en cours de développement. La deuxième année, la consommation augmente, mais reste souvent inférieure au niveau promis. La troisième année, le modèle s'est établi et l'entreprise est liée à un pool de crédits qui ne sera jamais utilisé.

Le scénario inverse est tout aussi coûteux. Si la consommation dépasse le pool convenu dans le contrat, SAP facture des frais de dépassement qui sont nettement plus élevés que le prix prévu dans l'accord initial. Un engagement trop faible déclenche des opérations de réapprovisionnement coûteuses à des prix que vous n'avez pas négociés.

Capex devient Opex

Une migration est coûteuse - les coûts varient selon la complexité entre deux millions et plus d'un milliard de dollars américains. Gartner prévoit des périodes de trois à sept ans. En plus de l'implémentation, le changement de licence pèse sur le budget : le passage des licences ECC à Rise transforme les actifs immobilisés (Capex) en coûts d'exploitation (Opex). Certes, SAP attire les clients avec des crédits de migration limités dans le temps, mais ceux-ci expirent souvent dès le premier renouvellement du contrat.

Le schéma typique : la première année, les coûts de Rise semblent encore être à parité avec les anciens coûts de maintenance. Jusqu'à la cinquième année, ils dépassent de loin les anciens coûts totaux (TCO) en raison des facteurs d'escalade et des modules supplémentaires - alors que le pouvoir de négociation et les anciennes licences sont perdus depuis longtemps. Le crédit de migration a disparu. La licence perpétuelle a disparu. Le pouvoir de négociation a disparu. Lorsque SAP a lancé Rise en 2021, l'entreprise a utilisé les Full User Equivalents comme principale mesure de licence pour les abonnements au cloud. Au lieu d'acheter un nombre fixe de licences pour chaque type d'utilisateur, vous vous abonnez à un pool d'UFC.

FUE : La métrique pour SAP Rise

La pondération est définie avec précision. SAP positionne le FUE comme une flexibilité. Vous n'êtes pas lié à des comptages rigides pour chaque type d'utilisateur. Vous pouvez redistribuer au sein du pool si vos besoins évoluent. Si dix utilisateurs Core ont besoin d'un accès Advanced, vous déplacez des capacités sans acheter de nouvelles licences. Le risque réside dans l'abstraction.

Les Full User Equivalents (FUE) convertissent un nombre concret d'employés en un nombre pondéré qui dissimule le coût réel par utilisateur. Si votre contrat Rise couvre 500 FUEs à 2000 euros par FUE, cela correspond à un million d'euros par an. Mais 500 FUE pourraient représenter 500 utilisateurs Advanced, 2500 utilisateurs Core ou 15 000 utilisateurs Self-Service. Le coût par personne varie entre 2000 euros et 66,66 euros selon la composition.

L'échéance de 2027 va aller et venir. Mais les contrats que vous signez aujourd'hui sous la pression vous accompagneront pendant au moins cinq ans. La question décisive pour votre business case est donc la suivante : „Quel avenir sera inaccessible si nous n'investissons pas stratégiquement aujourd'hui ?“

(Source : DLC)